專案資訊

• 專案代號：humanize

技術配置

生產環境

通訊協議

以往的經驗都在開發 Restful 服務，對 GraphQL 的議題並不熟悉。有鑒於 Restful 為人所知的效能問題，前端的資料結構被後端 API 侷限，因而花費更多請求來取得相同的資訊。這些都是促使我想嘗試 GraphQL 的理由。

• GraphQL

語言框架

這邊主要選擇個人熟悉或社群常用的框架。

• TypeScript
• NestJS
• Apollo

 npm i -g @nestjs/cli

nest new --strict humanize-api

npm i @nestjs/graphql @nestjs/apollo @apollo/server graphql

工具模組

用於計算星盤的函式庫。內建資料可計算 3000 BC 至 3000 AD，精準度 0.1 弧秒。若下載 JPL 資料集（約 2.9 GB），可計算 13000 BC 至 17000 AD，精準度小於 0.001 弧秒。

• Swiss Ephemeris

npm i swisseph

開發環境

設計模式

目標設計為微服務，因此預先選用 CQRS 讀寫分離的模式，並搭配 Sega 模式設計非同步業務邏輯，以確保最終一致性。

• CQRS

npm install --save @nestjs/cqrs

測試框架

毫無懸念。

• Jest

語法檢查

特別加上 simple import sort 是因為受不了雜亂無章參差不齊的 import 語句。

• Eslint
• eslint-plugin-simple-import-sort

除了使用 NestJS 預設 strict 模式的語法檢查之外，另外還調整了一些規則：

• 限制 interface 命名須以大寫 I 開頭

'@typescript-eslint/naming-convention': [
  'error',
  {
    selector: 'interface',
    format: ['PascalCase'],
    custom: {
      regex: '^I[A-Z]',
      match: true,
    },
  },
],

• 強制宣告方法和類別函數的返回型態

'@typescript-eslint/explicit-function-return-type': 'error',

• 強制宣告導出的方法和類別函數的參數和返回型態

'@typescript-eslint/explicit-module-boundary-types': 'error',

• 禁止使用 any

'@typescript-eslint/no-explicit-any': 'error',

• 強制宣告類別成員和函數的存取層級

'@typescript-eslint/explicit-member-accessibility': 'error',

• 強制要求 return throw continue break 語句的上一行須為空白行

'padding-line-between-statements': [
  'error',
  { blankLine: 'always', prev: '*', next: 'return' },
  { blankLine: 'always', prev: '*', next: 'throw' },
  { blankLine: 'always', prev: '*', next: 'continue' },
  { blankLine: 'always', prev: '*', next: 'break' },
],

• 排序導入及導出

'simple-import-sort/imports': 'error',
'simple-import-sort/exports': 'error',

• 單行程式碼長度 80 字以內

'max-len': ['error', { code: 80 }],

版本控制

• git
• gitmoji
  • 因為可愛🥰以後要接 CD 的話，還可以使用 semantic-release 搭配自己寫的 semantic-release-gitmoji

自動化流程

• Husky
  • 初始化 git hook
• Lintstaged
  • 對暫存的變更執行語法檢查和格式化

晚安，瑪卡巴卡。